1. Field of Art
The disclosure generally relates to the field communication protocols for communicatively coupling peripheral devices to host devices.
2. Description of the Related Art
Generally, a host (or primary) device, for example, a mobile computing device 110, may seek to communicate with an accessory (or peripheral) device that seems to connect with it. However, host devices generally use higher-level programming languages such as JavaScript while low-level accessory devices generally do not provide register mapping that supports such a high-level programming language. Thus currently, there is no way for a host device using a high-level language such as JavaScript or other virtual machine/scripting languages to directly drive or operate a peripheral device.
Hot pluggable peripheral device communication buses are well known in the art. For example, universal serial bus (USB) is an external bus standard that supports data transfer rates of up to 12 megabits per second. A single USB port can be used to connect many peripheral devices, such as mice, modems, keyboards, and the like. Another external bus standard is IEEE 1394, also commonly referred to as Firewire-I-link and/or Lynx. IEEE 1394 is a very fast external bus standard that supports data transfer rates of up to 400 megabits per second. A single IEEE 1394 port can also be used to connect several external devices. Both IEEE 1394 and USB support plug and play and hot plugging installations, and also provide power to the connected peripheral devices.
The problem with USB and IEEE 1394 is that they require complex communication protocols to handle bus arbitration functionality and other complex communication tasks. In many instances, these complex protocols are not necessary and it is desirable to have a more simplified communication protocol. For example, when dealing with peripheral devices with simple I/O functions such as lights, switches, temperature sensors, ambient lights etc., it is preferable to have a simple communications protocol which is fast.
Another method for communicatively coupling a host device using a higher-level computer program with an accessory device is to use a device driver. Device drivers, implemented as software modules or components that can be integrated into an operating system, are typically used to provide well defined software application program interfaces (APIs) to the operating system and application programs for each of the hardware interfaces. Device drivers often provide a degree of device independence or virtualizing that may simplify the interaction of an application program or operating system with the specifics of a particular class of hardware interface.
Conventionally, a device driver must be downloaded and installed for each peripheral device connected to the host device. In such a case, there is always a possibility that a host device user will perform an improper operation in installing the peripheral device driver software. That may particularly be the case if the device driver software includes device drivers for several different peripheral devices and/or if the host device user is required to make certain selections or settings during installing the device driver software, which can increase the chance of the computer user making errors in installing the device driver software
Moreover, from the vantage point of the manufacturer of the peripheral device, requiring packaging the device driver software with each peripheral device has the obvious drawback of increasing costs. Moreover, it often occurs that errors in device drivers are discovered or device drivers are updated after they have been shipped with peripheral devices. In that instance, the device driver software provided with the peripheral device may not be the most up-to-date version of the device driver or may contain minor flaws or bugs, which is also obviously problematic for the computer user.